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I  Overview 


•  The  Federal  Reserve  Bank  of  Boston  (FRBB)  has  met  with  IT  vendors  famihar  with 
check  processing  and  FRB  applications  and  solicited  proposals  in  answer  to  an  RFP 
for  check  image  processing  and  archive  and  retrieval  systems.  The  responses  are 
informative  in  regard  to  FRB  ideas  and  flinctional  requirements,  but  do  not  present  a 
solution  that  will  do  a  specified  job,  and  vendors  do  not  discuss  steps  that  would 
enable  them  to  take  the  responsibility  for  arriving  at  a  solution. 

•  It  would  have  been  more  desirable  for  vendors  to  take  a  proactive  approach  and  use 
the  tables  of  data  on  check  volumes  in  the  back  of  the  RFP  together  with  assumptions 
based  on  discussions  and  experience  with  the  FRB  as  well  as  the  functional 
requirements  in  the  RFP  to  develop  a  proposal  to  achieve  an  assumed  set  of  results,  or 
what  might  have  been  called  a  "strawman".  The  proposals  could  have  been  compared 
more  adequately  if  that  had  been  done,  and  it  would  have  been  possible  to  work  with  a 
selected  vendor(s)  to  modify  proposals  and  meet  a  more  exactly  defined  set  of 
requirements. 

•  The  FRB  did  not  specify  the  volumes  of  items  that  would  be  received  from  processing 
or  anticipated  retrieval  levels  to  be  supported  in  the  RFP  (current  or  projected).  This 
tended  to  make  vendors  take  more  general  approaches  to  the  RFP. 

•  The  vendors  are  also  used  to  working  with  the  FRB  with  less  than  perfect  or  complete 
requirements.  Steps  have  been  taken  in  the  past  to  incrementally  improve  systems  as 
they  are  implemented  or  after  they  have  been  implemented.  This  type  of  approach 
could  be  much  more  risk  prone,  costly  and  time  consuming  than  expected  with  a  step 
as  radical  as  the  introduction  of  imaging  and  the  truncation  of  paper  checks.  Imaging 
has  proved  to  be  a  step  that  has  more  of  an  impact  on  business  processes  than  usually 
anticipated. 


II      Review  of  Vendor  Responses 


A.  CBIS 

CBIS  demonstrates  knowledge  of  the  FRB  check  processing  environment  in  the 
considerations  given  to  storage  capacity.  CBIS  has  worked  with  the  FRB  in  Dallas 
and  Minneapolis. 

CBIS  points  out  several  ways  to  guard  against  disaster  and  aid  recovery.  One  is  to  use 
RAID  level  5.  Another  is  to  have  a  backup  global  site.  (CBIS  recommends  a  two 
tiered  index,  global  and  local,  with  a  central  site  handling  global  indexes  to  point  to 
local  sites  that  have  the  archives.) 

Although  responses  to  requirements  can  be  explored  in  the  CBIS  proposal,  it  is  not 
possible  to  match  all  the  information  or  responses  provided  by  CBIS  to  the  RFP.  It  is 
difficult  to  confirm  that  all  the  items  in  the  RFP  have  been  addressed.  It  would  be 
helpful  if  CBIS  added  references  in  their  proposal  to  the  corresponding  items  in  the 
RFP  as  BancTec  does  or  refers  to  the  number  for  requirements  used  in  the  RFP  as 
IBM  does  in  their  response. 

CBIS  also  does  not  attempt  to  meet  all  the  items  in  the  RFP.  CBIS  notes  that 
modification  is  needed  to  meet  space  and  system  requirements  for  JPEG  or  other 
compression/decompression  techniques.  The  RFP  has  several  references  to  the  need 
for  this  capability  (one  is  numbered  12.1.1.17).  CBIS  notes  that  it  has  major  concerns 
for  the  overall  impact  of  FEDNET,  but  the  RFP  states  that  it  must  be  used  for 
communication  between  Reserve  Banks  (12.7. 1 . 1).  More  should  be  said  if  there  are 
major  concerns. 

CBIS  includes  the  ESCON  driver  among  its  components  for  the  system,  but  notes  that 
this  driver  must  be  developed,  and  states  that  this  would  be  done  in  the  time  required 
to  develop  the  system  to  meet  the  RFP.  There  is  insufficient  detail  provided  to  predict 
how  long  it  will  take  to  develop  the  system.  In  addition,  it  might  be  desirable  to  have 
this  capability  ready  for  testing  at  an  earlier  date. 

Although  it  is  noted  that  Sybase  would  be  used  in  retrieval,  the  reference  to  this 
product  is  brief  CBIS  does  have  experience  with  this  product  for  similar  applications, 
but  there  have  been  questions  about  the  use  of  Sybase  with  large  databases.  It  should 
be  verified  that  these  problems  have  been  overcome  in  further  evaluation  of  the  CBIS 
proposal. 

Although  statements  are  made  about  achieving  various  response  times  for  retrievals, 
these  are  not  made  in  relation  to  anticipated  volumes  of  work  at  a  site.  An  attempt  is 
not  made  to  match  the  operation  of  the  system  as  a  whole  against  some  model  or 
assumed  set  of  work. 
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B.  BancTec 


Responses  in  the  BancTec  proposal  refer  to  requirements  in  the  FRB  RFP.  They 
appear  to  respond  to  all  requirements. 

BancTec  has  put  thought  into  the  responses  to  the  RFP.  There  are  discussions  of 
sizing  the  archive  storage  for  each  level  as  well  as  recommending  what  equipment  will 
be  used  for  each  level.  Nearline  access  is  also  recommended  for  the  first  three  months 
of  level  II  archiving. 

The  proposal  includes  the  use  of  an  "Optimizer"  software  capability  for  the  purpose  of 
throttUng  reads  and  writes  during  times  of  high  activity  so  that  retrieval  can  take  place. 
The  "optimizer"  capability  should  be  used  for  whatever  system  is  finally  obtained. 

Considerable  detail  is  provided  on  indexing  structures  that  go  beyond  the  Treasury 
application  and  address  needs  for  commercial  check  truncation  and  image  retrieval 

Despite  the  depth  of  the  BancTec  proposal,  it  is  not  possible  to  match  it  against  a 
model  of  the  work  volumes  and  RFP  requirements  which  are  necessary  to  accomplish 
the  FRB  archive  and  retrieval  job. 

There  are  also  questions  about  the  depth  of  resources  that  BancTec  can  devote  to 
problems  that  might  occur. 

The  selection  of  the  DEC  Alpha  computer  as  a  component  of  the  solution  raises 
questions.  The  current  sales  volume  for  the  Alpha  and  the  cash  flow  of  DEC  make  the 
future  of  DEC  not  as  secure  as  might  be  desired.  Major  vendors  of  the  past  have 
halted  support  for  equipment  in  order  to  remain  viable.  Even  if  DEC  and  the  Alpha 
succeed  there  might  be  steps  to  reduce  support  for  software  products  in  the  future 
which  would  be  important  to  the  FRB  such  as  open  system  products,  DCE,  JPEG  or 
other  components  of  the  solution.  DEC  has  halted  support  for  software  products  in 
the  past.  INPUT  would  recommend  that  an  alternative  equipment  choice  such  as  HP 
or  Sun  also  be  considered  in  relation  to  BancTec. 
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C.  ffiM 


IBM  responses  to  requirements  in  the  proposal  are  coded  with  the  numbering 
convention  in  the  RFP.  This  makes  it  possible  to  review  the  proposal  and  confirm  that 
responses  are  there  or  not.  Although  all  requirements  are  addressed,  the  responses  for 
many  items  are  brief  or  not  substantial  enough  to  confirm  that  the  requirement  is  fully 
recognized  and/or  supported. 

The  selection  of  components  is  not  related  to  or  discussed  in  relation  to  the  need.  This 
increases  attention  that  must  be  given  to  the  selection  of  equipment  and  particularly 
the  selection  of  archival  equipment.  IBM  recommends  the  use  of  automated  tape 
library  equipment  for  archive  levels  II  and  III,  although  the  other  three  vendors 
recommend  optical  storage  or  jukeboxes  for  level  II  in  order  to  improve  the  speed  of 
retrieval.  Tape  libraries  are  only  recommended  for  level  III.  Has  IBM  performed 
calculations  that  show  the  ATL  units  are  sufficient  for  level  II? 

IBM  has  not  considered  the  use  of  nearline  with  devices  in  archive  level  II  or  III 
although  other  vendors  recommend  this.  Have  the  other  vendors  or  IBM  performed 
calculations  that  show  that  this  is  or  is  not  needed? 

IBM  has  also  bid  a  tape  storage  unit,  NP-2,  that  will  not  be  available  until  the  third 
quarter  of  1995.  No  suggestions  for  the  means  of  estimating  the  response  time  of  a 
system  with  this  unit  before  it  is  available  have  been  made.  Also  this  type  of  unit  has 
been  delayed.  StorageTek  might  be  one  alternative  to  consider  if  IBM  thought  that 
StorageTek's  large  scale  automated  tape  library  (Iceberg)  would  satisfy  timing 
requirements. 

IBM  has  proposed  the  use  of  the  RS/6000  running  AIX  or  OS/2  as  an  open  system. 
Retrieval  units  were  mentioned  that  would  use  DOS.  (DOS  may  be  phased  out  as  a 
product  supported  by  Microsoft  with  the  shipment  of  Windows  95.)  The  use  of 
Windows  or  other  vendor-neutral  versions  of  UNIX  are  not  discussed.  This  will  not 
allow  software  to  be  developed  that  can  be  used  on  a  wide  range  of  open  systems. 

IBM  has  also  proposed  the  use  of  DB2  on  the  RS/6000  which  can  also  run  on  some 
open  systems  such  as  HP  and  Sun  (Solaris).  This  might  limit  alternatives  in  the  fliture. 
Considerable  investment  is  being  made  by  IBM  in  DB2  at  this  time,  so  the  use  of  this 
product  could  have  advantages.  Past  users  of  DB2  question  whether  the  software 
technology  isn't  limited  by  its  original  design  and  continued  use.  They  point  out  that 
current  DB2  users  have  been  given  some  assurance  of  compatibility  between  the 
downsized  product  and  the  mainframe  one.  They  also  point  out  that  some  features  of 
the  downsized  DB2  may  be  two  to  three  years  behind  features  contained  in  Oracle  or 
Sybase. 
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IBM  is  recommending  a  number  of  software  packages  as  components  of  the  system 
including  DCE  (which  can  improve  security),  Netview  (which  will  provide  network 
management),  EIF  for  distribution,  and  DB2  for  the  database.  This  could  save 
development  time  and  cost.  The  combination  could  also  result  in  a  less  than  optimal 
response  to  work  situations  if  the  components  do  not  interoperate  adequately  in  the 
FRBB's  unique  environment.  Tests  would  have  to  be  held  to  ensure  that  components 
work  together  in  a  manner  that  would  meet  FRBB  work  requirements. 

IBM  has  offered  a  product  oriented  solution  which  has  response  characteristics  that 
meet  RFP  requirements,  but  there  is  no  discussion  of  the  timing  considerations 
involved  in  handling  items  fi"om  processing  together  with  retrieval  at  peak  periods. 
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D.  Unisys 


Although  a  systematic  use  of  references  are  not  made  to  the  RFP  functional 
requirements,  it  appears  possible  to  compare  responses  to  requirements  as  stated  in  the 
RFP. 

The  review  of  storage  for  archive  levels  discusses  the  volume  and  timing  requirement 
problems  that  can  exist  for  the  application.  Unisys  makes  several  recommendations 
about  alternative  approaches  to  archiving  that  suggests  they  have  a  strong  feeling  for 
the  timing  considerations. 

A  recommendation  is  made  to  use  Oracle  for  retrieval  at  each  of  the  FRB  district 
offices  (with  a  copy  at  each)  in  order  to  divide  up  the  work.  Since  the  FRB  office  is 
identified  in  the  DIN  forwarded  from  RHA,  it  is  possible  to  do  this.  However,  this 
would  be  difficult  to  expand  to  commercial  check  truncation  since  searches  could  be 
made  on  criteria  that  did  not  include  the  Fed  district  code.  It  is  unlikely  that  any  effort 
at  changes  in  operation  or  standardization  could  overcome  this.  Consequently,  it 
would  be  necessary  to  broadcast  retrieval  requests  to  all  district  offices  for  some 
inquiries  that  would  arise  in  commercial  check  processing. 

Unisys  is  planning  to  use  two  small  software  companies  for  vital  pieces  of  software 
needed  to  implement  their  solution. 

The  Unisys  project  management  plan  indicates  that  a  preliminary  limited  system  will  be 
implemented  first.  It  also  indicates  that  the  FRBB  will  be  required  to  generate  a  fiill 
requirements  document  as  the  first  step  of  development.  This  means  that  prices  and 
dates  will  not  be  pinned  down  until  this  document  is  reviewed  by  Unisys.  This 
represents  an  escape  hatch  for  Unisys  to  rethink  its  plans  based  on  the  final 
requirements  document. 

Unisys  has  not  attempted  to  formulate  and  respond  to  an  assumption  of  the  workload 
that  can  be  involved  in  handling  work  from  processing  together  with  retrieval  although 
questions  are  raised  about  what  is  needed  to  support  the  workload  as  Unsisys 
understands  it. 
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Ill  Conclusions 


•  The  contents  of  all  four  proposals  indicates  that  these  vendors  understand  the  archive 
and  retrieval  application  in  general.  Any  one  of  the  vendors  might  be  able  to  work 
with  the  FRB  to  generate  a  workable  solution.  However,  there  is  a  high  level  of  risk 
in  implementing  a  successful  solution  and  possibility  of  much  higher  than  anticipated 
cost  and  time  with  this  type  of  application. 

•  It  is  difficult  to  relate  the  proposal  responses  since  they  don't  use  a  common 
convention  for  responses.  CBIS  seems  to  have  the  most  gaps  in  terms  of  the 
requirements  in  the  RFP  as  noted  in  the  prior  section. 

•  The  proposals  all  have  gaps  in  relation  to  the  requirements  in  the  RFP  and/or  raise 
questions  about  their  responses  particularly  in  regard  to  the  dynamic  situations  that 
must  be  handled. 

•  There  are  different  approaches  to  the  storage  used  for  archives  and  to  the  construction 
of  indexes.  There  are  also  differences  in  the  DBMS  products  recommended  to 
manage  the  index  database.  (Unisys  recommends  the  use  of  the  DBMS  at  all  district 
offices  to  introduce  another  differentiation.)  There  is  also  no  way  to  compare  the 
differences  in  approaches  since  there  isn't  a  model  or  statement  of  assumed 
requirements  in  any  proposal  to  relate  the  other  proposals  to. 

•  It  appears  that  the  vendors  expect  a  decision  to  be  made  on  their  discussion  of 
capabilities  and  components. 

•  It  must  be  recognized  that  the  way  that  the  FRBB  has  proceeded  in  the  past  to 
develop  applications  by  migrating  toward  a  solution  with  a  vendor  could  be  very 
expensive,  time  consuming  and  prone  to  major  problems  with  an  imaging  approach. 

One  major  project  that  involved  implementing  an  imaging  system  to  replace  paper 
document  handling  at  a  major  airline  nearly  ended  in  disaster  although  the  vendor 
had  a  high  level  of  knowledge  in  imaging.  A  leading  SI  vendor  with  expertise  in 
BPR  had  to  rethink  processes  and  have  major  segments  of  software  recoded  to 
rescue  the  effort. 

Several  imaging  systems  that  INPUT  came  in  contact  with  during  interviews  had 
major  problems  that  led  to  the  consideration  of  legal  action. 

Another  major  integrator  and  Big  6  firm  has  stated  to  INPUT  that  imaging  usually 
requires  BPR  work  since  it  involves  basic  changes  in  procedures. 
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IV  Recommendations 

•  If  further  comparisons  will  be  made  of  proposals,  steps  should  be  taken  to  make  it 
easier  to  accomplish.  For  instance,  CBIS  should  be  asked  to  code  or  supply  references 
in  their  proposal  so  that  it  can  be  compared  to  the  RFP. 

•  Before  a  decision  is  made,  steps  should  be  taken  to  make  it  possible  to  compare 
vendor  responses.  This  would  involve  work  by  the  FRB  to  specify  volumes  of  check 
image  work  (and  ranges  of  such  work)  that  it  wanted  vendors  to  respond  to.  Vendors 
would  have  to  develop  a  model  that  showed  how  archiving  and  retrieval  work  was 
affected.  The  model  could  be  automated  or  manual  based  on  experience.  It  could  be  a 
series  of  spread  sheets  that  could  be  adjusted  or  changed  in  relation  to  the 
specifications  developed  by  the  FRB.  The  vendors  should  develop  their  models  with 
the  assumption  that  the  FRB  will  develop  benchmarks  based  on  them  for  use  in 
measuring  performance  of  test  and  installed  systems.  The  benchmark  might  be 
constructed  to  reflect  the  results  predicted  by  a  model  with  an  allowance  of  5%  for 
instance. 

•  At  this  point,  only  an  incomplete  comparison  can  be  made  between  the  vendors  as 
shown  in  Exhibit  A.  CBIS  stands  out  as  the  vendor  which  least  meets  the  RFP  and 
might  be  eliminated  on  that  basis.  Unisys  appears  most  responsive  to  the  requirement 
for  open  systems  and  might  be  easy  to  initiate  since  it  offers  a  preliminary  approach  for 
the  initial  system.  However,  the  Unisys  approach  could  cause  most  problems  in  the 
extension  of  the  use  of  images  in  commercial  banking.  Also,  Unisys  places  most 
pressure  on  the  FRBB  in  its  project  management  plan  which  emphasizes  that  the 
FRBB  has  the  responsibility  for  drawing  up  final  requirements  without  any  indication 
that  Unisys  would  respond  with  a  model  or  analysis  to  pin  down  costs  or  elapsed  time. 
BancTec  offers  the  advantage  of  the  most  understanding  of  the  imaging  application 
including  archive  retrieval,  and  IBM  seems  to  rely  most  on  its  past  acquaintance  with 
check  processing  although  it  offers  certain  risks  in  its  recommendation  of  hardware 
and  software  products.  No  selection  can  be  made  between  Unisys,  BancTec  and  IBM 
without  testing  a  solution  or  having  these  vendors  develop  models  (or  even  a  set  of 
spreadsheets)  that  respond  to  a  range  or  set  of  work  volumes  including  retrievals  as 
discussed  above.  Those  models  or  spreadsheets  can  serve  as  the  basis  of  a  decision 
with  the  other  information  available  including  pricing,  and  they  can  also  be  expressed 
in  benchmarks  (with  an  allowance  as  suggested)  which  the  winning  vendor  can  be  held 
to. 

•  INPUT  or  another  consultant  would  be  able  to  assist  in  developing  the  specification 
ranges  needed  to  compare  vendor  solutions  and  in  packaging  this  information  for  use 
by  vendors. 
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EXHIBIT  A 

Preliminary  Qualitative  Comparison  of  Proposals 
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BancTec  Unisys 
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Ability  to  Guarantee 
Time  and  Cost 


Cannot 


Cannot  Cannnot  Cannot 

(Most  risk) 


Where: 


X  =  low  level 

XX  =  medium  level 

XXX  =  highest  level 


•  The  vendors  could  start  to  develop  their  models  before  the  specification  ranges  are 
developed  by  the  FRB.  They  will  have  to  be  informed  of  this  requirement  in  a  written 
document  that  points  out  the  advantages  that  they  as  well  as  the  FRB  will  gain,  and 
the  alternatives  mentioned  above  will  have  to  be  spelled  out.  It  may  also  be  necessary 
to  have  a  member  of  your  committee  or  a  consultant  or  both  work  with  them  to  insure 
that  the  task  is  done.  This  approach  will  only  be  meaningful  if  two  or  more  vendors 
proceed  with  it.  For  this  reason,  all  four  vendors  could  be  asked  to  respond. 

•  An  analysis  of  the  FRBB  specification  ranges  and  vendor  models  together  with 
associated  work  activities  should  be  conducted  to  uncover  possible  problems  in 
business  processes  and  steps  that  can  be  taken  to  overcome  them.  This  step  would  be 
an  alternative  to  a  BPR  exercise  which  would  be  extremely  difficult  to  carry  out  at  this 
stage.  INPUT  is  prepared  to  assist  in  supporting  this  activity. 

•  Since  this  image  processing  and  archive/retrieval  application  will  require  ongoing 
review  and  planning,  it  would  be  wise  not  to  rely  on  the  availability  of  the  systems 
architects  used  by  a  vendor  in  design  and  implementation  of  the  system.  There  have 
been  questions  in  regard  to  back  up  high  level  staff"  at  all  vendors.  The  FRBB  should 
consider  hiring  a  systems  architect  who  is  familiar  with  the  application  during  project 
implementation  and  turnover. 
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